1. Field of the Invention
This invention relates generally to communication systems, and, more particularly, to wireless communication systems.
2. Description of the Related Art
Conventional wireless communication systems use various authentication techniques to protect the security and/or integrity of information transmitted through the system. For example, an Authentication and Key Agreement (AKA) protocol has been implemented in the Third Generation Partnership Project (3GPP) authentication infrastructure. The 3GPP AKA protocol may be leveraged to enable application functions in the network and/or on the user side to establish shared keys using a bootstrapping technique.
FIG. 1 conceptually illustrates a conventional model of a bootstrapping architecture 100 that is based on the 3GPP AKA protocol. The bootstrapping architecture 100 includes a Home Subscriber Server (HSS) that is coupled to a Bootstrapping Server Function (BSF) by an interface Zh. The BSF is coupled to one or more User Equipment (UE, also commonly referred to as mobile units) by an interface Ub. The BSF is also connected to a Network Application Function (NAF) by an interface Zn. The NAF is coupled to the UE by an interface Ua. The entities included in the bootstrapping architecture 100 are described in detail in the 3GPP Technical Specification 3GPP TS 33.220 V6.3.0 (2004-12), which is hereby incorporated herein by reference in its entirety. The 3GPP Technical Specification 3GPP TS 33.220 V6.3.0 (2004-12) will be referred to hereinafter as the 3GPP Technical Specification.
FIG. 2 conceptually illustrates a conventional bootstrapping procedure 200. The UE may initiate the bootstrapping procedure 200 by sending a request towards the BSF, as indicated by arrow 205. The BSF may retrieve user security settings and/or authentication data, such as an Authentication Vector, from the HSS, as indicated by double arrow 210. The BSF sends an authentication request (indicated by the arrow 215) to the UE. The authentication request 215 may be formed based upon the user security settings and/or authentication data retrieved from the HSS. The authentication request 215 may include random numbers and/or authentication tokens that may be used in the authentication process. The UE performs (at 220) Authentication and Key Agreement procedures to verify that the authentication request is from an authorized network. The UE may also calculate various session keys and/or a digest AKA response.
The digest AKA response is sent to the BSF (as indicated by the arrow 225), which may authenticate (at 230) the UE based upon the digest AKA response. The BSF may then generate (at 230) one or more keys (Ks), as well as one or more lifetimes of the keys. A confirmation message including the keys and, if available, the key lifetimes may be sent to the UE, as indicated by the arrow 235. In response to receiving the confirmation message, the UE may generate (at 240) one or more keys (Ks), which should correspond to the one more keys (Ks) generated by the BSF. The UE and the BSF may use the keys (Ks) to generate key material Ks_NAF that may be used for communication between the UE and an NAF.
FIG. 3 conceptually illustrates a conventional method 300 of forming a secure communication link between a UE and an NAF. The UE derives (at 305) key material Ks_NAF using the key (Ks) and then transmits an application request to the NAF, as indicated by the arrow 310. The application request 310 typically includes a bootstrapping transaction identifier (B-TID), as well as other information. The NAF transmits an authentication request to the BSF, as indicated by the arrow 315. The authentication request 315 includes the B-TID and a NAF host name. The BSF provides an authentication answer, as indicated by the arrow 320. The authentication answer 320 typically includes key material Ks_NAF derived from the key (Ks), as well as any appropriate key lifetimes. The key material Ks_NAF is stored (at 325) by the NAF and an application answer is provided to the UE, as indicated by arrow 330. Once the method 300 of forming the secure communication link is complete, the UE and the NAF may communicate securely through the interface Ua shown in FIG. 1.
Conventional bootstrapping procedures, such as the 3GPP GBA architecture described above, are not typically able to create fresh key material associated with a NAF (Ks_NAF) unless the key material (Ks) is changed or updated. This may expose the system to security risks and/or decrease the efficiency of the system. For example, if a NAF does not incorporate replay protection, then inadvertent reuse of the same Ks_NAF may expose the NAF to a replay attack. The NAF can specify that each time a Ks_NAF is requested then the corresponding key material (Ks) should also be updated, but this requires the designer of the service to be security aware. In practice, designers may be unaware of the security risk or they may not have the time or expertise to modify the NAF to prevent replay attacks by regularly updating the key material (Ks). Furthermore, replay protection or fresh Ks_NAF may not be necessary when the system is first deployed, but over time the use of the NAF may evolve such that replay attacks become a concern. The designer of the NAF may decide to err on the side of safety and specify that whenever the NAF requests Ks_NAF, the UE should update the key material (Ks). Although this approach may increase security, it may also reduce the efficiency of the system. For example, the HSS may have to be contacted repeatedly to update the key material (Ks), which may increase traffic to legacy authentication systems. Repeated interaction with the HSS may also increase the time that a UE waits for the service provided by NAF to begin.
The GBA architecture specified in the 3GPP Technical Specification may or may not allow parallel independent sessions between the same pair of UE and NAF. In particular, the 3GPP Technical Specification does not provide clear guidelines for providing key material to parallel sessions. For example, the 3GPP Technical Specification specifies that the UE may store at most one Ks_NAF key per NAF_Id. The 3GPP Technical Specification also states that only the corresponding Ks_NAF is updated when the UE and NAF agree on new key material (Ks). All other Ks_NAF relating to other NAF_Ids stored in the UE should not be affected.
The ambiguity of the 3GPP Technical Specification leaves important questions unresolved. For example, a NAF may specify that a key material (Ks) update will be requested for every session (e.g., because the NAF does not have replay protection). When a first session is established between the UE and the NAF, the key material (Ks) may be updated and a session key (Ks_NAF) may be stored on the UE. If a second parallel session is established concurrently with the first session, the key material (Ks) may again be updated and a new session key may be formed. The 3GPP Technical Specification does not, however, specify which of the session keys should be stored in the UE.